…dupe pre-image reads (#3018 review)

Two hardening follow-ups from the #3018 adversarial review.

① Predicate guard order-independence for writes. #2982 made bulk update/delete
carry opCtx.ast, first bringing them under the step-2.9 anti-oracle guard. That
guard is documented to inspect the CALLER's own predicate (RLS/sharing filters
legitimately reference caller-unreadable fields like owner_id), but for a bulk
write it inspected opCtx.ast.where — which plugin-sharing (a sibling middleware
of unguaranteed order) may already have composed an owner_id match into. On an
object whose owner_id is FLS-hidden that could 403 a legitimate bulk write. The
guard now inspects opCtx.options.where (the caller's untouched predicate) for
update/delete, making it independent of middleware order and unable to mistake
an injected filter for a probe. Reads unchanged.

② Pre-image read dedup. A single readRowById helper (fail-closed: missing
engine / null id / thrown read → null, which always denies) now backs the
provenance gates, and a memoized getCallerPreImage collapses the owner-anchor
echo (3.5) and RLS check post-image (3.6) — the identical (object, id,
caller-context) row — into one read per operation. Pure refactor; the ~5 inlined
read sites can no longer drift.

Tests: plugin-security 463 (+1 new: injected owner_id in the AST does not trip
the guard, a caller filtering a hidden field still does); dogfood owner-anchor /
two-doors / CBP / invoice-cbp / private-owd green.